nit tests are very useful for checking how our app is working.
Otherwise, we run into all kinds of issues later on.
In this article, we’ll look at some best practices we should follow when writing JavaScript unit tests.
Tag Our Tests
We should tag our tests so that they can run when commits are being made or builds are being run.
This way, we can, we can do sanity checks before we commit anything by running the most critical tests.
For instance, we can write:
describe("user service", function() {
describe("log in #sanity", function() {
test("can log in with the right username and password #sanity", function() {
//...
});
});
});
Categorize Tests Under at Least 2 Levels
We should apply some structure to our test suite so that anyone can understand the requirements.
Categorizing tests will improve the readability of test reports.
We can just go to the desired section and find out the cause of failures.
For example, we can categorize them by writing:
describe("user service", () => {
describe("log in", () => {
it("user can log in with right username and password", () => {});
it("should return error with wrong username or password", () => {});
});
});
A bit of nesting helps us find our tests easier.
Backend Testing
Our testing portfolio can be improved with tests other than unit tests.
We also look at integration tests and end to end tests to improve our testing portfolio.
3 kinds of tests together will have more comprehensive testing coverage that just unit tests.
There’re many things that unit tests don’t cover like inter-service calls and message queues that don’t get tested with unit tests.
But they can be tested with end to end tests.
We can follow the testing pyramid with lots of unit tests, some integration tests, and a few end to end tests for testing the most critical parts of our app.
Component Testing
Unit tests cover a tiny portion of an app and it’s expensive to cover everything with them.
End to end tests can cover multiple parts of an app but they’re flaky and slower.
A balanced approach would be more appropriate.
We can write things that are bigger than unit tests and smaller than end to end tests.
They can test components, which is a unit.
We can test the whole API without mocking anything that belongs to the microservice itself.
We have the real database, at least an in-memory version.
This can let us gain more confidence in our tests.
We still stub external APIs and other external dependencies.
Ensure New Releases Don’t Break the API
To make sure that we don’t break anything when we release our API to clients, we should test the contract of our API.
This way, we know when we make a request with the given payload, we get the same response that the client expects.
This ensures that we can test our API before clients get their hands on their API.
Conclusion
We can tag our tests to make them run during commits quickly.
Also, we categorize our tests to make them easier to find.
We can also add component tests to make sure we don’t break anything.
